The "_too_small" test variants intentionally configure an isolated buffer
pool with only 2 buffers to validate proper error handling when the pool
is exhausted during notification of 16 msg_subscriber observers. These
tests are likely to fail on SMP systems due to a buffer recycling race
condition:

Expected behavior (uniprocessor):
  Publisher Thread:
    1. Allocate buf1 for bar_msg_sub1 ✓
    2. k_fifo_put(sub1_fifo, buf1)
    3. Allocate buf2 for bar_msg_sub2 ✓
    4. k_fifo_put(sub2_fifo, buf2)
    5. Try allocate buf3 for bar_msg_sub3 → FAIL -ENOMEM

  Subscriber threads process messages after notification completes,
  pool exhausts at subscriber #3 as expected.

SMP race condition:
  CPU 0 (Publisher):         CPU 1 (bar_msg_sub1):  CPU 2 (bar_msg_sub2):
  ------------------         ---------------------  ---------------------
  Alloc buf1 ✓
  k_fifo_put(sub1, buf1)
                             k_fifo_get() → buf1
                             zbus_sub_wait_msg()
                             net_buf_unref()
                             → buf1 FREED!
  Alloc buf2 ✓
  (reuses buf1!)
  k_fifo_put(sub2, buf2)
                                                    k_fifo_get() → buf2
                                                    net_buf_unref()
                                                    → buf2 FREED!
  Alloc buf3 ✓
  (reuses buf1 again!)
  ...continues...
  All 16 allocations succeed!

On SMP systems, subscriber threads on other CPUs may consume and free
buffers quickly enough that they are recycled back to the pool before the
publisher's notification loop can exhaust it. The test's assumption that
notification completes before subscribers run does not hold with parallel
execution.

Since this is a test design limitation (not a zbus bug), filter SMP
configurations from these specific test variants rather than attempt to
artificially slow down subscribers or change thread priorities.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>

Map all pins of RT685's Flexcomm #1 peripheral.

Needed for opration of Flexcomm #1 in I2S mode or Flexcomm #3 in I2S
mode with shared signals.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>

Add SCK and WS signals to a shared signal set between Flexcomm #1 and
Flexcomm #3 for the mimxrt685_evk/mimxrt685s/cm33.

This enables the board to both transmit and receive audio, as the BCK
and WS signals produced by the WM8904 codec are only connected to the
Flexcomm #1 peripheral.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>